The former is just too long, see the examples in `hygiene.rs`

Some `unwrap` uses here, but they are on paths involving item kinds that
are known to have an identifier.

Again by using `Option<Symbol>` to represent "no name".

`sym::dummy` also appears to work.

It's a much better name, more consistent with how we name such things.

Also rename `Lifetime::res` as `Lifetime::kind` to match. I suspect this
field used to have the type `LifetimeRes` and then the type was changed
but the field name remained the same.

This adds two new warnings, both of which print the attribute
incorrectly as `#[]`. The next commit will fix this.

The current code assumes that the attribute is just an identifier, and
so misprints paths.

This shows places where the use of `name_or_empty` causes problems, i.e.
we print empty identifiers in error messages:
```
error: unrecognized field name ``
error: `` isn't a valid `#[macro_export]` argument
`#[no_sanitize()]` should be applied to a function
```
(The last one is about an attribute `#[no_sanitize("address")]`.)

The next commit will fix these.

I'm removing empty identifiers everywhere, because in practice they
always mean "no identifier" rather than "empty identifier". (An empty
identifier is impossible.) It's better to use `Option` to mean "no
identifier" because you then can't forget about the "no identifier"
possibility.

Some specifics:
- When testing an attribute for a single name, the commit uses the
  `has_name` method.
- When testing an attribute for multiple names, the commit uses the new
  `has_any_name` method.
- When using `match` on an attribute, the match arms now have `Some` on
  them.

In the tests, we now avoid printing empty identifiers by not printing
the identifier in the `error:` line at all, instead letting the carets
point out the problem.

Type ascription syntax was removed in 2023.

hygiene: Rename semi-transparent to semi-opaque

"Semi-transparent" is just too damn long for a name, especially when used multiple times on a single line, it bothered me when working on rust-lang#139083.

An optimist sees a macro as semi-opaque, a pessimist sees it as semi-transparent.
Or is it the other way round?

Use a session counter to make anon dep nodes unique

This changes the unique session hash used to ensure unique anon dep nodes per session from a timestamp to a counter.

This is nicer for debugging as it makes the dep graph deterministic.

…onszelmann

Remove `name_or_empty`

Another step towards rust-lang#137978.

r? `@jdonszelmann`

Fix `register_group_alias` for tools

In clippy we're looking at renaming `clippy::all` and registering an alias for it but currently that doesn't work for tools

The `lint_ids` of the alias are now populated at the time of registration to make it easier to handle

…=BoxyUwU

Rename `LifetimeName` as `LifetimeKind`.

It's a much better name, more consistent with how we name such things.

Also rename `Lifetime::res` as `Lifetime::kind` to match. I suspect this field used to have the type `LifetimeRes` and then the type was changed but the field name remained the same.

r? `@BoxyUwU`

…illaumeGomez

Remove `kw::Empty` uses in rustdoc

Helps with rust-lang#137978.

r? `@GuillaumeGomez`

Include optional dso_local marker for functions in `enum-match.rs`

This PR adds the `dso_local` marker to the `enum-match.rs` test annotations for all the `match\d+` functions. These markers are added by LLVM when targeting `aarch64-unknown-none` even though they are missing in `aarch64-unknown-linux-gnu`. This is causing a CI error when running the codegen suite on the `aarch64-unknown-none` target for ferrocene.

r? `@scottmcm`

parser: Remove old diagnostic notes for type ascription syntax

Type ascription syntax was removed by rust-lang#109128 in 2023, so “remove this again in a few months” is long overdue.

Happily, this also reduces the amount of parser diagnostic code that cares whether the compiler is unstable.

---

See also the recent rust-lang#138898, which removed some other related dead code but declined to touch the diagnostics.

It's possible that some of these parser tests are no longer useful at all, but I haven't investigated them for this PR.

…onszelmann

fix for multiple `#[repr(align(N))]` on functions

tracking issue: rust-lang#82232
fixes rust-lang#132464

The behavior of align is specified at https://doc.rust-lang.org/reference/type-layout.html#r-layout.repr.alignment.align

> For align, if the specified alignment is less than the alignment of the type without the align modifier, then the alignment is unaffected.

So in effect that means that the maximum of the specified alignments should be chosen. That is also the current behavior for `align` on ADTs:

```rust
#![feature(fn_align)]

#[repr(C,  align(32), align(64))]
struct Foo {
    x: u64,
}

const _: () = assert!(core::mem::align_of::<Foo>() == 64);

// See the godbolt LLVM output: the alignment of this function is 32
#[no_mangle]
#[repr(align(32))]
#[repr(align(64))]
fn foo() {}

// The current logic just picks the first alignment: the alignment of this function is 64
#[no_mangle]
#[repr(align(64))]
#[repr(align(32))]
fn bar() {}
```

https://godbolt.org/z/scco435jE

https://github.com/rust-lang/rust/blob/afa859f8121bf2985362a2c8414dc71a825ccf2d/compiler/rustc_middle/src/ty/mod.rs#L1529-L1532

The rust-lang#132464 issue is really about parsing/representing the attribute, which has already been improved and now uses the "parse, don't validate" attribute approach. That means the behavior is already different from what the issue describes: on current `main`, the first value is chosen. This PR fixes a logic error, where we just did not check for the effect of two or more `align` modifiers. In combination, that fixes the issue.

cc `@jdonszelmann` if you do have further thoughs here